home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2001 May / SGI IRIX Base Documentation 2001 May.iso / usr / share / catman / a_man / cat1 / rsvpd.z / rsvpd
Encoding:
Text File  |  2001-04-17  |  14.7 KB  |  331 lines
  1.  
  2.  
  3.  
  4. RRRRSSSSVVVVPPPPDDDD((((1111MMMM))))                                                            RRRRSSSSVVVVPPPPDDDD((((1111MMMM))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      rsvpd - Resource ReSerVations Protocol daemon
  10.  
  11. SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
  12.      rrrrssssvvvvppppdddd [ ----DDDD ] [ ----dddd _d_e_b_u_g__b_i_t_s ] [ ----llll _l_o_g_g_i_n_g__l_e_v_e_l ] [ ----RRRR _r_o_u_t_e_r__a_d_d_r ] [
  13.      ----tttt _m_s_t_a_t__T_T_L ] [ ----eeee _M_I_B__e_n_t_r_y__p_u_r_g_e__m_i_n_u_t_e_s ] [ ----cccc _c_o_n_f_i_g__f_i_l_e ]
  14.  
  15. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  16.      _R_s_v_p_d is a daemon program that uses the RSVP resource reservation
  17.      protocol to set up reservation state in hosts and routers.  It supports
  18.      an API that allows applications to make reservation requests.  It
  19.      includes an adaptation module to the admission control and traffic
  20.      control mechanisms provided by the output device drivers in the kernel.
  21.  
  22.      rsvpd contains a SNMP agent, called rsvpd-snmpagent.  The rsvpd-snmpagent
  23.      allows SNMP managers to read all RSVP and Integrated Service MIB
  24.      variables, and to write the intSrvIfAttribMaxAllocatedBits variable.  See
  25.      _r_s_v_p_d-_s_n_m_p_a_g_e_n_t(_1_m) for more details.
  26.  
  27.  
  28. OOOOPPPPTTTTIIIIOOOONNNNSSSS
  29.      ----DDDD   Execute rsvpd in debugging mode, i.e., do not detach the process,
  30.           and print debugging information to stderr.
  31.  
  32.      ----dddd   Set the debugging mask to the integer _d_e_b_u_g__b_i_t_s.  This mask selects
  33.           which additional information, if any, will be logged when the
  34.           logging level (see below) is at least LOG_DEBUG.  See the section
  35.           below on LOGGING CONTROLS.
  36.  
  37.      ----llll   Set the logging level, which controls logging of data for debugging
  38.           and diagnosis, to the integer _l_o_g_g_i_n_g__l_e_v_e_l.  See the section below
  39.           on LOGGING CONTROLS.
  40.  
  41.      ----RRRR   Specify _r_s_v_p__r_o_u_t_e_r as the name or dotted-decimal number of a
  42.           first-hop router to be used by _r_s_v_p_d running on a host.  With this
  43.           parameter, _r_s_v_p_d will send a unicast copy of any UDP-encapsulated
  44.           RSVP message directly to _r_s_v_p__r_o_u_t_e_r, in addition to copies it
  45.           normally sends.  The ----RRRR parameters is required only when the
  46.           multicast TTL threshold of a tunnel or firewall would otherwise make
  47.           the first-hop router inaccessible from the host.
  48.  
  49.      ----tttt   Set the IP TTL value for multicasting diagnostic information
  50.           (summary of the state) to _m_c_a_s_t__T_T_L.  This information is multicast
  51.           when the DEBUG_MCAST_STATE bit (see LOGGING CONTROLS) is set in the
  52.           debugging bit mask.  The default is TTL = 1, i.e., one hop.  ----eeee
  53.           Controls how long an old MIB entry will be kept before it is
  54.           deleted.  An old MIB entry is one that is no longer active because
  55.           the session, sender, reservation, forwarded reservation, or flow
  56.           that it describes is no longer active.  The default is 5 minutes.
  57.           Delaying the deletion of an inactive MIB entry gives network
  58.           managers some time to examine the entry after receiving the lostFlow
  59.           notification.  ----cccc Specify another location for the configuration
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. RRRRSSSSVVVVPPPPDDDD((((1111MMMM))))                                                            RRRRSSSSVVVVPPPPDDDD((((1111MMMM))))
  71.  
  72.  
  73.  
  74.           file.  The default is /etc/config/rsvpd.conf.
  75.  
  76. CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN FFFFIIIILLLLEEEE
  77.      By default, the RSVP daemon looks for a configuration file named
  78.      _r_s_v_p_d._c_o_n_f in /etc/config.  This file may contain configuration commands,
  79.      one command per line.  Each command consists of a series of keywords
  80.      separated by blanks or tabs; some keywords are followed by one or two
  81.      parameters.  The first keyword in the line is the name of the command;
  82.      other keywords may come in any order.  A blank line or a comment line
  83.      beginning with '#' will be ignored.
  84.  
  85.      There is currently two commands defined:
  86.  
  87.          iiiinnnntttteeeerrrrffffaaaacccceeee _i_f_a_c_e__n_a_m_e [police] [udpencap] [udpttl _n_n]
  88.  
  89.                      [refresh _r_r] [disable] [passbreak] [passnormal]
  90.  
  91.                      [integrity] [sendkey _i_d _k_e_y]
  92.  
  93.          nnnneeeeiiiigggghhhhbbbboooorrrr _h_o_s_t [sendkey _i_d _k_e_y]
  94.  
  95.      Here _i_f_a_c_e__n_a_m_e is the name of a physical interface (e.g., `le0'), to
  96.      which the following keywords apply.  Similarly, _h_o_s_t is the name or
  97.      dotted-decimal address of a neighboring host.  More than one command line
  98.      may be given for the same interface or host, and corresponding lines have
  99.      a cumulative effect.
  100.  
  101.      The following keywords are defined for the iiiinnnntttteeeerrrrffffaaaacccceeee command:
  102.  
  103.      ppppoooolllliiiicccceeee
  104.           Traffic control policing is to be applied to the specified
  105.           interface.
  106.  
  107.      uuuuddddppppeeeennnnccccaaaapppp
  108.           Force _r_s_v_p_d to use UDP encapsulation of RSVP messages on the
  109.           specified interface.  In most cases _r_s_v_p_d will automatically
  110.           configure itself to do UDP encapsulation on any interfaces on which
  111.           it is required.  The uuuuddddpppp keyword should be required only by a router
  112.           connected to a LAN which has no hosts that act as RSVP senders.
  113.  
  114.      uuuuddddppppttttttttllll ttl
  115.           UDP encapsulation using the specified TTL is to be performed on RSVP
  116.           messages sent out the specified interface.  This keyword implies the
  117.           uuuuddddpppp keyword.  The default TTL for encapsulation is 1.
  118.  
  119.           The uuuuddddppppttttttttllll keyword is required only when the local environment
  120.           includes RSVP-capable hosts separated by non-RSVP-capable routers,
  121.           or to satisfy TTL threshold requirements.  The TTL value must not
  122.           exceed the hop distance to the first-hop router; violation of this
  123.           restriction will cause gratuitous UDP encapsulation between routers.
  124.  
  125.  
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. RRRRSSSSVVVVPPPPDDDD((((1111MMMM))))                                                            RRRRSSSSVVVVPPPPDDDD((((1111MMMM))))
  137.  
  138.  
  139.  
  140.      ddddiiiissssaaaabbbblllleeee
  141.           Disable RSVP on the specified interface.  No RSVP messages are
  142.           forwarded on this interface.  This option is useful to prevent RSVP
  143.           messages from ever reaching certain parts of the network.
  144.  
  145.      ppppaaaassssssssbbbbrrrreeeeaaaakkkk
  146.           Forward RSVP PATH messages as normal, but set the RSVP TTL field so
  147.           that the next hop router will think this hop does not support RSVP.
  148.           Kernel admission and traffic control is bypassed.  All reservation
  149.           requests are accepted.  This option is useful on systems with some
  150.           interfaces which do not support RSVP admission and traffic control.
  151.           RSVP messages are still forwarded on those interfaces; however,
  152.           other nodes will know what those interfaces do not support RSVP
  153.           traffic control.
  154.  
  155.      ppppaaaassssssssnnnnoooorrrrmmmmaaaallll
  156.           Process the RSVP messages normally, but bypass kernel admission and
  157.           traffic control.  All reservation requests are supported.  This
  158.           option is useful for high speed interfaces which do not support RSVP
  159.           admission and traffic control.  However, because of their high
  160.           bandwidth, they are unlikely to be a bottleneck for the flow.  This
  161.           option allows those interfaces to pretend they support RSVP traffic
  162.           control, even though they don't.  IP over ATM and HIPPI interfaces
  163.           are good candidates for this option.
  164.  
  165.      rrrreeeeffffrrrreeeesssshhhh _t_i_m_e
  166.           Override the default refresh period for the specified interface.
  167.           Here _t_i_m_e is a new refresh period in seconds. [Not supported yet].
  168.  
  169.      iiiinnnntttteeeeggggrrrriiiittttyyyy
  170.           Integrity checking is required on messages received on the specified
  171.           interface.
  172.  
  173.      sssseeeennnnddddkkkkeeeeyyyy _i_d _k_e_y
  174.  
  175.           Here _i_d is an integer key id and _k_e_y is a corresponding key for
  176.           sending messages to the specified interface.  _K_e_y must be 16 bytes
  177.           written in hexadecimal notation, with no spaces.
  178.  
  179.      rrrreeeeccccvvvvkkkkeeeeyyyy _i_d _k_e_y
  180.  
  181.           Here _i_d is an integer key id and _k_e_y is a corresponding key for
  182.           receiving messages from the specified neighbor node.  _K_e_y must be 16
  183.           bytes written in hexadecimal notation, with no spaces.
  184.  
  185. Here is an example configuration file
  186.                 # rsvpd configuration
  187.                interface le0   udpttl 3   integrity refresh 60
  188.                interface le0  sendkey 32  c0640a4abda195de6062afe2de5a7e47
  189.                interface le0  sendkey 33  7fa12385f3ac29b333715ff314d56fc9
  190.                neighbor can.isi.edu recvkey 77
  191.           32fc719d796f2ad764f36cf072dfc5d4
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. RRRRSSSSVVVVPPPPDDDD((((1111MMMM))))                                                            RRRRSSSSVVVVPPPPDDDD((((1111MMMM))))
  203.  
  204.  
  205.  
  206.               neighbor can.isi.edu recvkey 78
  207.           68fa01780355d7772997e5bf92927985
  208.  
  209.  
  210.  
  211. LLLLOOOOGGGGGGGGIIIINNNNGGGG CCCCOOOONNNNTTTTRRRROOOOLLLLSSSS
  212.      The RSVP daemon logs state and event information for management,
  213.      diagnosis, and debugging.  The logged data is written into an rsvpd log
  214.      file (e.g., /_v_a_r/_t_m_p/._r_s_v_p_d._l_o_g).  It also appears on the console
  215.      (stderr) if _r_s_v_p_d is executed in non-daemon mode (i.e., with the ----DDDD
  216.      flag).  The rsvpd log file can grow to a maximum size of approximately
  217.      400KB; it will then be closed and renamed to /_v_a_r/_t_m_p/._r_s_v_p_d._l_o_g._p_r_e_v,
  218.      and a new log file will be started.
  219.  
  220.      Logging is controlled by two integer parameters, the `debugging mask' and
  221.      the `logging level'.  These parameters may be set on the rrrrssssvvvvppppdddd command
  222.      line or dynamically using the rrrrttttaaaapppp console interface (see rtap(8)).
  223.  
  224.      Each log message has a priority, and it will appear in the log if its
  225.      priority is at least equal to the logging level.  The priorities (defined
  226.      in <_s_y_s/_s_y_s_l_o_g._h>) used by _r_s_v_p_d are as follows:
  227.  
  228.  
  229.      3    LOG_ERR
  230.           These messages indicate system errors, configuration errors,
  231.           internal logical errors within rsvpd, or logical errors in the
  232.           client end of an API socket.  They should never occur in normal
  233.           operation.
  234.  
  235.      4    LOG_WARNING
  236.           These messages indicate temporary resource shortage or protocol
  237.           errors in RSVP messages received from remote hosts.
  238.  
  239.      6    LOG_INFO
  240.           These message log changes of management parameters.
  241.  
  242.      7    LOG_DEBUG
  243.           These message contain debugging information.  This will generally
  244.           consist of a one-line summary of the event.  Then additional
  245.           information may follow, depending upon the setting of the debugging
  246.           mask bits DEBUG_IO and DEBUG_EVENTS.
  247.  
  248.      8    LOG_HEXD
  249.           Dump all RSVP messages sent and received in hex.
  250.  
  251.      For example, a logging_level of LOG_DEBUG will cause all events that
  252.      occur to be logged, while a logging_level of LOG_INFO will log everything
  253.      but debug messages.
  254.  
  255.      The debugging mask is considered to be a set of bits; the bits and their
  256.      symbolic designations in the code are as follows:
  257.  
  258.  
  259.  
  260.  
  261.                                                                         PPPPaaaaggggeeee 4444
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268. RRRRSSSSVVVVPPPPDDDD((((1111MMMM))))                                                            RRRRSSSSVVVVPPPPDDDD((((1111MMMM))))
  269.  
  270.  
  271.  
  272.      1    DEBUG_IO
  273.           If this bit is included, the contents of the each RSVP message will
  274.           be formatted to the log following its transmission or receipt.
  275.  
  276.      2    DEBUG_DS_DUMP
  277.           If this bit is included, the complete path and reservation state
  278.           will be written into the log, periodically and when the state
  279.           changes.
  280.  
  281.      4    DEBUG_EVENTS
  282.           If this bit is included, additional details on API and kernel
  283.           scheduling events will be logged following the corresponding event
  284.           lines.
  285.  
  286.      8    DEBUG_ROUTE
  287.           If this bit is included, a great deal of information concerning
  288.           route lookups will be logged.
  289.  
  290.      16   DEBUG_MCAST_STATE
  291.           This bit does not control logging.  If it is on, _r_s_v_p_d will
  292.           multicast its internal state periodically.  The RSVP tool _r_s_v_p_e_e_p
  293.           will receive and format this information.  The multicast TTL may be
  294.           set using the ----tttt parameter (see above).
  295.  
  296.      32   DEBUG_TIMERS
  297.           If this bit is included, a great deal of information concerning the
  298.           timer queue will be logged.
  299.  
  300.  
  301. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  302.      rtap(1m), rstat(1m), rsvpeep(1m), rsvpfilter(1m), psifconfig(1m), rsvpd-
  303.      snmpagent(1m)
  304.  
  305. SSSSGGGGIIII NNNNooootttteeeessss
  306.      The rsvpd in IRIX6.5 is based on ISI rel4.1a6.  It has been compiled
  307.      without OBSOLETE_API defined.
  308.  
  309.      The IRIX6.5 kernel supports Controlled Load traffic control, so rsvpd has
  310.      been compiled with the SCHEDULE option defined.
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.                                                                         PPPPaaaaggggeeee 5555
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.